<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<div class="article_body" id="nei">
    <div>
        <p>
            用了这么久的Git，一直没有用心学过，碰到过很多棘手的问题，一旦力所不能及，首先想到的就是用SourceTree替自己解决，最后问题虽然解决了，但自己还是没学会怎么用Git，于是决定趁着这个机会简单梳理一下自己经常会用到的几个命令。</p>
        <h3>从 add 到 commit </h3>
        <p>
            虽然一直在用着Git这个东西，也一直混迹于GitHub，但是对Git用法的掌握一直停留在表面。刚开始接触Git的时候，只知道Git有工作区，缓存区以及历史区，那时候只知道添加到缓存区： <code>git
            add</code>
            和添加到历史区： <code>git commit -m</code>
            ，后来用的多了，又学到了把这两个操作合并起来的： <code>git commit -a</code>
            。 </p>
        <h3>merge VS rebase </h3>
        <p>
            只在本地操作肯定是不行的，慢慢地接触到了远端，然后就学会了 <code>git push</code>
            和 <code>git pull</code>
            ，但这些操作都是只在 <code>master</code>
            这一个分支上，后来有一天老大说：以后我们再开发新功能或者修复BUG的时候需要新建一个分支，然后提Merge Request，然后自己又去百度怎么创建新分支： <code>git checkout -b</code>
            ，那时候感觉切换分支是一个特别神奇的事情，只需要一行命令，瞬间整个工作区的文件都不一样了。接触到分支以后，自然而然就遇到了分支合并的问题，然后就面临了 </p>
        <pre class="hljs nginx"><span class="hljs-attribute">git</span> merge develop
</pre>
        <p>和</p>
        <pre class="hljs nginx"><span class="hljs-attribute">git</span> rebase master develop
</pre>
        <p>
            的抉择，从字面上就可以分析到， <code>merge</code>
            是将目标分支上和当前分支上对比没有的commit信息重复一遍并且记录下一个新的commit向后人解释：我在此庄严宣布，我又和develop合并了，现在我们的状态是统一的。 </p>
        <p>
            而 <code>rebase</code>
            这个如果纯直译的话，应该是：变基，通俗来讲就是： <code>develop</code>
            由于和 <code>master</code>
            分开太久，在分开的这段时间里， <code>master</code>
            可能和别人有过一些交流导致它前进了几步，这时候 <code>develop</code>
            为了也保持与时俱进，决定变基！最终的效果就是 <code>develop</code>
            上有了 <code>master</code>
            上所有的commit信息，而 <code>develop</code>
            上的那些commit由于 <code>rebase</code>
            ，会丢掉时间信息，其他信息还是会保留，这个其实是通过 <code>patch</code>
            实现的，在下面我们会详细解释 <code>patch</code>
            的操作。 <code>rebase</code>
            操作的好处就是没有多余的commit，而且整体历史前进是呈线性的，就好比一棵树在树顶长出一个小树枝，这时候这棵树还是只有一条线，虽然可能因为这个树枝长而显得有点弯，后来慢慢地在小树枝生长的同时，树冠也在长，这时候就形成了枝杈，因为有了枝杈的存在，这棵树不再是纯线性，然后这时候如果把这个树枝砍下来，然后重新接在当前树冠的位置，这时候这个树枝就莫名前进了一段距离，保证了这棵树还是只有一条线，这就是
            <code>rebase</code>
        </p>
        <h3>修订历史：reset &amp; –amend </h3>
        <p>如果就一直这样平平稳稳的前行，莫非不是一件好事，但是这显然是不可能的，直到有一天，我提交了一个错误的commit，急忙去搜索怎么弥补我这样的错误，然后就学到了两种不同的解决方式：</p>
        <pre class="hljs sql">git <span class="hljs-keyword">reset</span> <span class="hljs-comment">--soft HEAD^</span>
</pre>
        <p>和</p>
        <pre class="hljs nginx"><span class="hljs-attribute">git</span> commit --amend -m <span class="hljs-string">"The new commit message"</span>
</pre>

        <p>
            其中， <code>reset</code>
            是用于修改历史版本，并且跟上 <code>--soft</code>
            是会将回退的commit中所作的一些修改放在缓存区，默认的 <code>--mixed</code>
            会将那些修改放回工作区，不在缓存区，而 <code>--hard</code>
            会将工作区以及缓存区和历史区都回退到特定的commit状态，会导致修改丢失，所有用这个的时候需要考虑清楚。 </p>
        <p>
            <code>commit --amend</code>
            没有 <code>reset</code>
            的功能那么强大，它只能修改你上一个commit，比如你还有一些修改也需要提交到上一个commit或者commit的信息有误，都可以通过这个命令进行修改。 </p>
        <h3>进入正题：patch </h3>
        <p>
            上面其实都是扯闲篇，真正今天要说的其实是另外一个东西： <code>patch</code>
            ，因为之前没有遇到过与之相关的需求，所有就素未谋面，今天终于碰到了相应的问题，于是急忙去补了一下课，在此就随便写一下。 </p>
        <h4>patch的作用 </h4>
        <p>
            <code>patch</code>
            直译过来就是补丁的意思，如果把我们的工作比作是在堆一个乐高机器人，我们的每一个commit都是一块小积木，我们每完成一个commit，这个机器人就更完善一点，而 <code>patch</code>
            就像是有我们已经有一个完成度比较高的机器人，然后另外有一个类似的乐高机器人可能也需要我们当前这个机器人的某个组件，它们不想再做重复性的工作，于是决定从我们这里copy一份，通过的手段就是我们根据现有东西生成一个补丁给它，然后它把这个补丁打上，就有了一个和我们一模一样的模块，我们来简单看一下这个过程都会涉及到哪些命令。
        </p>
        <h4>生成patch：diff || format-patch </h4>
        <p>首先是第一步：生成一个补丁文件，这个过程，又有两种不同的方法来实现，第一种是： </p>
        <pre class="prettyprint hljs lua">git diff  &gt; patch
git diff  <span class="hljs-comment">--cached &gt; patch</span>
git diff  branchname <span class="hljs-comment">--cached &gt; patch</span>
</pre>
        <p>
            运行其中任意一条命令都会在当前目录下生成一个patch文件，然后就可以拿着这个patch文件去应用了，这几个命令的不同在于 <code>--cached</code>
            ，加上这个是对比缓存区和历史区，不加这个是对比工作区和缓存区。 </p>
        <p>另外一种生成patch文件的方式是： </p>
        <pre class="prettyprint hljs tcl">git <span class="hljs-keyword">format</span>-patch <span
                class="hljs-number">0</span>f500e4...d37885d
git <span class="hljs-keyword">format</span>-patch <span class="hljs-number">-1</span> -o simple_fix.patch
git <span class="hljs-keyword">format</span>-patch <span class="hljs-number">0</span>f500e4
</pre>
        <p>
            通过 <code>format-patch</code>
            可以生成某个commit和另一个commit之间若干个commit合成的patch文件（包含收尾两个commit），或者最近若干个commit，或者自某一个commit以来所有的commit形成的patch文件（不包含指定的commit），还可以用
            <code>-o filename</code>
            或 <code>--stdout &gt; filename</code>
            定义patch文件输出路径。 </p>
        <p>
            这两种生成patch文件的不同在于：前者生成的patch文件是兼容性更强，不局限于git；而format-patch生成的patch文件只能在git中使用，但是后者生成的patch会保留patch开发者的信息，这对版本管理来说是很有帮助的，所有我们最常用的还是
            <code>format-patch</code>
            。 </p>
        <h4>应用patch </h4>
        <p>拿到patch文件之后，就是应用补丁，在直接应用补丁之前，我们还可以进行一些额外的操作，比如查看patch文件具体有哪些修改或者检查补丁文件是否有冲突，会涉及到下面两个命令： </p>
        <pre class="prettyprint hljs lua">git apply <span class="hljs-comment">--stat fix_empty_poster.patch</span>
git apply <span class="hljs-comment">--check fix_empty_poster.patch</span>
</pre>
        <p>如果验证了patch文件没有问题，那么就可以应用了 </p>
        <pre class="hljs nginx"><span class="hljs-attribute">git</span> am -s &gt; fix_empty_poster.patch
</pre>
    </div>

</div>
</body>
</html>

